home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Libris Britannia 4
/
science library(b).zip
/
science library(b)
/
COMMUNIC
/
BULLETIN
/
0340A.ZIP
/
ODOC_000.ARC
/
OPUS_SYS.DOC
next >
Wrap
Text File
|
1987-01-05
|
153KB
|
3,528 lines
############
## ##
## ##
## ## ######## ## ## #######
## ## ## ## ## ## ##
## ## ## ## ## ## #######
## ## ## ## ## ## ##
############ ######## ######### #######
##
##
##
##
----------------------------------
Computer-Based Conversation System
by Wynn Wagner III
Matrix 124/108
----------------------------------
Questions regarding Opus should be directed to:
OPUSinfo Here modem (214) 991-3381 1/113
OPUSinfo There modem (415) 753-3356 1/114
OPUS - Copyright (c) 1986, 1987 by Wynn Wagner III
All rights reserved
OPUS is militantly public domain. This means you may NOT sell
OPUS or any part of it to anybody for any reason.If you do, then
you are required to make a contribution of $50 to:
The Shanti Project
896 Hayes Street
San Francisco, CA 94117
Attn: Director of Development
Please mention that your contribution is for OPUS.
Hopefully, the contribution will be tax-deductible -- you will
receive an acknowledgement directly from The Shanti Project.
"It was the Law of the Sea, they said.
Civilization ends at the waterline. Beyond
that, we all enter the food chain, and not
always right at the top."
--- Hunter S. Thompson
Documentation by David Finster, Mike Kelleher, Mike Elkins, Wynn
Wagner, and Jon Sabol.
TABLE OF CONTENTS
INTRODUCTION
What's an "OPUS?" . . . . . . . . . . . . . . . . . . . 1
About This Document . . . . . . . . . . . . . . . . . . 1
What does OPUS really mean? . . . . . . . . . . . . . . 2
The Rules for Using OPUS . . . . . . . . . . . . . . . 2
The Rules on Transferring OPUS Software . . . . . . . . 2
List of Things Borrowed, not Blue . . . . . . . . . . . 3
Legal Stuff . . . . . . . . . . . . . . . . . . . . . . 3
Version Numbers . . . . . . . . . . . . . . . . . . . . 4
OVERVIEW
Equipment . . . . . . . . . . . . . . . . . . . . . . . 5
Hardware . . . . . . . . . . . . . . . . . . . . . 5
Software . . . . . . . . . . . . . . . . . . . . . 5
CONFIG.SYS File . . . . . . . . . . . . . . . 6
FILES=xx . . . . . . . . . . . . . . . . 6
BUFFERS=xx . . . . . . . . . . . . . . . 6
COUNTRY=xxx . . . . . . . . . . . . . . 6
DEVICE=ANSI.SYS . . . . . . . . . . . . 7
AUTOEXEC.BAT . . . . . . . . . . . . . . . . 7
OPUS!Comm . . . . . . . . . . . . . . . 7
Set TZ= . . . . . . . . . . . . . . . . 8
Functional Overview . . . . . . . . . . . . . . . . . . 9
The Matrix . . . . . . . . . . . . . . . . . . . . 9
Messages . . . . . . . . . . . . . . . . . . . . . 9
Local Messages . . . . . . . . . . . . . . . 9
Matrix Messages . . . . . . . . . . . . . . . 9
Broadcast Messages . . . . . . . . . . . . . 10
File Section . . . . . . . . . . . . . . . . . . . 10
Uploads . . . . . . . . . . . . . . . . . . . 10
Downloads . . . . . . . . . . . . . . . . . . 10
Matrix . . . . . . . . . . . . . . . . . . . 10
Operating Philosophy . . . . . . . . . . . . . . . . . 11
Differences Between OPUS and FIDO<tm> . . . . . . . . . 11
File Structures . . . . . . . . . . . . . . . . . 11
Extended Display File Capability . . . . . . . . . 12
Extended File Transfer Protocols . . . . . . . . . 13
EchoMail Enhancements . . . . . . . . . . . . . . 13
Mail Interface . . . . . . . . . . . . . . . . . . 13
Extended Message Area Attributes . . . . . . . . . 14
Message Area Commands . . . . . . . . . . . . . . 14
File Area Commands . . . . . . . . . . . . . . . . 15
Miscellaneous Commands . . . . . . . . . . . . . . 16
OPUS Sysop Manual - Page i
THE MESSAGE SECTION
What is a Message Section? . . . . . . . . . . . . . . 17
Setting up a Message Section . . . . . . . . . . . . . 17
System Files . . . . . . . . . . . . . . . . . . 17
Creating a System File . . . . . . . . . . . 17
Privilege . . . . . . . . . . . . . . . . . . 18
Setting Paths . . . . . . . . . . . . . . . . 18
BBS Path . . . . . . . . . . . . . . . . 18
Help Path . . . . . . . . . . . . . . . 19
Message Path . . . . . . . . . . . . . 19
File Path . . . . . . . . . . . . . . . 19
Titles . . . . . . . . . . . . . . . . . . . 19
Area Types . . . . . . . . . . . . . . . . . . . 20
Local . . . . . . . . . . . . . . . . . . . 20
Matrix . . . . . . . . . . . . . . . . . . . 20
EchoMail . . . . . . . . . . . . . . . . . . 20
Area Aspects . . . . . . . . . . . . . . . . . . . 21
Privilege Levels . . . . . . . . . . . . . . 21
Public-Only . . . . . . . . . . . . . . . . . 21
Private-Only . . . . . . . . . . . . . . . . 21
Public-or-Private . . . . . . . . . . . . . . 21
Read-Only . . . . . . . . . . . . . . . . . . 21
Anonymous-OK . . . . . . . . . . . . . . . . 22
Special Considerations for Matrix Messages . . . . . . 22
NetInfo . . . . . . . . . . . . . . . . . . . . . 22
OPUSnode . . . . . . . . . . . . . . . . . . . . . 22
Cost Accounting . . . . . . . . . . . . . . . . . 22
Handling Crashmail . . . . . . . . . . . . . . . . 23
Refuse Crashmail . . . . . . . . . . . . . . 23
After Crashmail Exit . . . . . . . . . . . . 23
IFNA<tm> Kludge . . . . . . . . . . . . . . . 23
Extract ARCmail . . . . . . . . . . . . . . . 24
After ARCmail Exit . . . . . . . . . . . . . 24
Default Settings . . . . . . . . . . . . . . . . . 24
MATRIX Assume vs. MATRIX Ask . . . . . . . . 24
Kill/Sent . . . . . . . . . . . . . . . 25
File Attach . . . . . . . . . . . . . . 25
WARNING!!! . . . . . . . . . . . . . . . 25
Crashmail . . . . . . . . . . . . . . . 25
File Request . . . . . . . . . . . . . . 25
Update Request . . . . . . . . . . . . . 26
Return Receipts . . . . . . . . . . . . 26
Audit Trail . . . . . . . . . . . . . . 26
Special Considerations for EchoMail . . . . . . . . . . 26
Configuration Note . . . . . . . . . . . . . . . . 26
Areas.Bbs . . . . . . . . . . . . . . . . . . . . 26
Origin Line . . . . . . . . . . . . . . . . . . . 27
Automatic Toss . . . . . . . . . . . . . . . . . . 27
Seenby Displays . . . . . . . . . . . . . . . . . 27
Processing Outbound EchoMail . . . . . . . . . . . 27
OPUS Sysop Manual - Page ii
Enhanced Message Area Commands . . . . . . . . . . . . 28
The Hurl Command . . . . . . . . . . . . . . . . . 28
The Forward Command . . . . . . . . . . . . . . . 28
Forward With Bombing Run . . . . . . . . . . . . . 28
The Zone Command . . . . . . . . . . . . . . . . . 29
Special Message Areas . . . . . . . . . . . . . . . . . 30
Hidden Areas . . . . . . . . . . . . . . . . . . . 30
Barricaded Areas . . . . . . . . . . . . . . . . . 30
Hints, Tricks, and Sleight of Hand . . . . . . . . . . 32
Directory Sorts . . . . . . . . . . . . . . . . . 32
Renumbering Message Areas . . . . . . . . . . . . 32
Disk Optimizing . . . . . . . . . . . . . . . . . 33
THE FILE SECTION
What is a File Section? . . . . . . . . . . . . . . . . 35
Configuring a File Area . . . . . . . . . . . . . . . . 35
Upload Path . . . . . . . . . . . . . . . . . . . 35
Download Path . . . . . . . . . . . . . . . . . . 35
Titles . . . . . . . . . . . . . . . . . . . . . . 35
Files.Bbs . . . . . . . . . . . . . . . . . . . . . . . 35
Comments . . . . . . . . . . . . . . . . . . . . . 36
End-of-List Character . . . . . . . . . . . . . . 36
Wildcards . . . . . . . . . . . . . . . . . . . . 36
Handling Dates . . . . . . . . . . . . . . . . . . 36
Quirks, Peculiarities, and Caveats . . . . . . . . . . 37
External File Transfer Programs . . . . . . . . . . . . 37
Sliding Window Kermit . . . . . . . . . . . . . . 38
Windowed Xmodem . . . . . . . . . . . . . . . . . 38
OPUS SYSOP SUPPORT
Installing OPUS Software . . . . . . . . . . . . . . . 39
The Control File . . . . . . . . . . . . . . . . . . . 39
The Control File Compiler . . . . . . . . . . . . . . . 39
Command Line Options . . . . . . . . . . . . . . . . . 39
Parameter File . . . . . . . . . . . . . . . . . . 40
Baud Rate . . . . . . . . . . . . . . . . . . . . 40
Time . . . . . . . . . . . . . . . . . . . . . . . 40
Port . . . . . . . . . . . . . . . . . . . . . . . 40
Unpack Mail . . . . . . . . . . . . . . . . . . . 40
The Sysop Menu ("!") . . . . . . . . . . . . . . . . . 40
A)rea Maintenance . . . . . . . . . . . . . . . . 41
D)elete Messages . . . . . . . . . . . . . . . . . 41
M)atrix Setup . . . . . . . . . . . . . . . . . . 41
E)vent Manager . . . . . . . . . . . . . . . . . . 42
O)utside Command . . . . . . . . . . . . . . . . . 42
Events . . . . . . . . . . . . . . . . . . . . . . . . 43
Embedded Commands . . . . . . . . . . . . . . . . . . . 43
User Access Levels . . . . . . . . . . . . . . . . . . 43
Sysop's Keyboard . . . . . . . . . . . . . . . . . . . 43
OPUS Sysop Manual - Page iii
APPENDICES
OPUS Program and Support File List . . . . . . . . . . 44
Embedded Commands . . . . . . . . . . . . . . . . . . . 46
For More information on OPUS . . . . . . . . . . . . . 54
OPUS Sysop Manual - Page iv
INTRODUCTION
What's an "OPUS?"
OPUS is a computer-based conversation system (CBCS) that
started with a conversation containing lines such as: "Gee,
wouldn't it be nice if..." That was in December of 1985, and
the current program reflects much in the way of enhancements
to existing <tm> bulletin board systems.
OPUS incorporates extensive messaging and conferencing
capabilities along with a sophisticated software exchange
system to create a fully interactive, user-friendly,
bulletin board system.
You'll find that OPUS is compatible with MOST of the support
file structures used by FIDO<tm> version 11w. OPUS is also
capable of receiving incoming Matrix traffic. This is
compatible with FIDOnet<tm> network protocols, including
SEAlink<tm>, a fast, full-duplex transfer protocol.
About This Document
This manual is supplied for reference to the sysop. It
assumes you have already installed OPUS, and it is running
properly. You will find many of the "bells and whistles"
OPUS has described here, although you won't find out how to
install it, or how to generate outgoing calls. These things
are best discussed in a separate document.
You should have received an installation program that will
setup a basic OPUS. It pretty well covers all the dynamics
of creating paths, and putting files in the right place. If
you are a new sysop, you probably will want to run with the
basic OPUS for a few weeks until you get comfortable with
the OPUS method of operation. Once you understand which
files do what, you should be ready to custom tailor OPUS for
your interests and desires. When you initially install OPUS,
you should keep it simple. Let OPUS do the work. It knows
what it needs and where, and you can run into very
perplexing problems if don't put things where they belong.
You can always modify the system at a later date without
reinstalling the software.
There is also a file called 'OPUSER.DOC'. This is the user's
guide to OPUS. It tells you what OPUS looks like from a
user's point of view. This will aid you greatly in
determining what features are available from what menus.
OPUS Sysop Manual - Page 1
What does OPUS really mean?
The word "opus" is Latin and means "project". Most folks
think that OPUS is an alcoholic penguin from the comic
strips. To tell you the truth, the guy who designed most of
the OPUS CBCS hadn't read the comics in years; he had no
idea why ANSI drawings of a rather perplexed bird started
appearing on OPUS opening screens.
We mention this for two reasons:
First, it underscores the philosophy behind OPUS. OPUS is
free, with no personal profit involved. We make no attempt
to control OPUS' use or to alter what you think about the
software, the matrix, or the state of the union. If you
think OPUS is a penguin, we think that's just fine. OPUS is
a tool for hobbyists, and should always be used for fun, not
profit, or gain.
Second, if you mention "foul" to any of us, we'll probably
think you mean a bug in the program, not a pitiable bird in
a tux.
It may be a bird to you -- and that's okay. We know one
thing for sure, in most cases, it's faster than a speeding
bullet!
The Rules for Using OPUS
You have only two obligations if you want to use the OPUS
system:
1. Be friendly about it. Don't start hollerin' at other
OPUS Sysops or at its creators or one of our Help
Nodes. OPUS is user-friendly software. You have to
be friendly to use it.
2. Don't use OPUS to break laws.
The Rules on Transferring OPUS Software
You are specifically forbidden, under the terms of your
limited license, to make money from the transfer of OPUS
software. OPUS software must always be free.
If your board charges a fee to users, then you may NOT keep
OPUS software on-line for download. You can run OPUS, but
you cannot distribute it because you charge money.
You cannot "bundle" OPUS software with any other product
when there is a fee for that product.
OPUS Sysop Manual - Page 2
User groups and other non-profit organizations can
distribute OPUS software on such things as "Disk of the
Month", as long as there is no charge over-and-above the
actual cost of the distribution diskette.
If you paid money for your copy of OPUS, please contact one
of the OPUSinfo systems. We want to know about it.
List of Things Borrowed, not Blue
We'd like to thank Ward Christiansen, who thought up the
whole idea of bulletin boards and without who we would not
electronic communications today. We also would like to thank
Chuck Forsberg, who has done more for file transfer protocol
improvements than any other single person.
A special thanks to the folks at Columbia University, for
their fine specification of sliding window Super-Kermit, and
Jan A. van der Eyk, for his implementation of the protocol
in CKERMIT.
The current structure of OPUS owes a debt of gratitude to
Tom Jennings, whose FIDO<tm> software and FIDONet<tm>
network protocol provided much ancestral inspiration.
CRC Routines. These were pillaged from a bulletin board. We
found no name on the routines, but we need to say thanks
anyway.
Widgets, such as the ability to display the contents of an
archive while online, were suggested by one of many sysops,
without whom there there'd be no need for you to read this.
System Enhancements Associates designed ARChive files, the
SEALink file transfer protocol, and ARCMail.
Bob Hartman created the communications driver OPUS!Comm, and
did a great deal of the file transfer code.
Jeff Rush designed EchoMail.
Legal Stuff
The SEALink file transfer protocol is copyrighted by System
Enhancements Associates, who decided not to charge for its
use if proper credit was given. We're giving that credit
now, and there is a brief copyright notice on the protocol
menu.
OPUS!Comm is copyrighted by Sparks Software, and is licensed
for use on this project.
OPUS Sysop Manual - Page 3
Version Numbers
Copies of OPUS always have at least numbers:
1.00
A major revision number change (such as from a 1.00 to a
2.00) is a serious change, and normally involves some
structure incompatibility between the old and new versions.
A conversion utility will be provided if possible. This
would be something like changing the user file format from a
FIDO<tm> compatible file to something a little more flexible
and more suited to OPUS' abilities.
On the other hand, a change from 1.00 to 1.10, isn't quite
as drastic. Usually this will reflect the addition of new
features that don't involve any major configuration changes.
An example would be adding an additional file transfer
protocol, or enhanced search functions in the message
section.
Finally, a move from 1.00 to 1.01 would be a very minor
change. Maybe changing the wording in a section of text or
something.
And now, back to the regular BBS...
OPUS Sysop Manual - Page 4
OVERVIEW
Equipment
Hardware
Currently, Opus runs on an IBM-Compatible computer, or a DEC
Rainbow with at least 128k of memory free. This means that
you should have at least 256k so that OPUS will have enough
memory after DOS and the driver programs are loaded. The
difference between the IBM and the DEC versions, is the
OPUS!Comm driver used. As of this writing, these are the
only two drivers available. However, the specs for OPUS!Comm
are public, and anyone who cares to can write drivers for
other MS-DOS machine. For details, contact Sparks Software.
Also, OPUS REQUIRES a storage device larger than a floppy
drive. Generally, this will be a hard drive, but can be
cartridge media such as a Bournoulli Box just as easily.
There are absolutely no plans to release a version that will
run on floppies; the support files simply take too much
room.
Theoretically, OPUS will use any modem that uses the Hayes
command set and supports DTR. It has been successfully
tested with the USR Courier, and the Hayes family. If you
use another modem type, OPUS should work, but is not
guaranteed. If you get other brands of modems to work with
OPUS, please contact one of the INFOnodes and let them know
the brand name and what you had to do to get it to work.
Software
Several pieces of software are required to make an OPUS
work. You must have DOS 2.1 or greater. OPUS will run under
DOS 2.1, but some of the features will not work. DOS 2.0 and
1.1 are NOT supported. DOS 3.1 is recommended for a fully
featured OPUS system.
You will also need to install the ANSI device driver that
comes with DOS (this is built into DEC's version of DOS) in
order to use the graphics capabilities of OPUS. ANSI allows
your computer to send escape codes to the remote computer to
tell it things like colors and cursor positioning. You can
install ANSI by copying the file ANSI.SYS to the root
directory of the drive your computer boots off of and adding
a line in Config.sys that reads:
device=ANSI.SYS
This will install the necessary driver to allow OPUS to use
graphics. If you see a lot of numbers,semi-colons, and left
square brackets when OPUS runs, you do not have ANSI
installed.
OPUS Sysop Manual - Page 5
CONFIG.SYS File
While we're on the subject of Config.sys, we might need to
say a few more things about it. Config.sys allows you to set
some of the operating parameters of your computer at boot
time. There are three main commands that directly affect
OPUS' performance:
1. FILES=xx
This statement tells DOS how many files a single
process may have open at one time. If a program
tries to use more files than DOS allows, it
generally does real nasty things; like deleting
the currently opened files to make room for new
files. Not a pretty sight. OPUS requires a
parameter greater than or equal to 20. DOS
allocates 48 bytes for each file defined in
Config.sys, So you can be pretty liberal in
allocating these. If you are running some sort of
multi-tasker, remember that your file handles are
divided by the number of tasks you have running.
That is, if you are running two programs, and you
have files set to 20, each task will be allowed to
open 10 files. This will not work with OPUS. You
will need to increase the number of files defined.
The maximum number of file handles you can
allocate is 255, but this is VERY excessive.
2. BUFFERS=xx
This tells DOS how much information to read in at
a time when a transfer is made from the disk to
memory. Each buffer takes 528 bytes, so you might
need to watch this if you are running in a limited
amount of space. Generally speaking, if you
specify too few buffers at boot time, you will
slow the system down. If you specify too many
buffers, you will slow the system down, so you
really need to experiment with this one. We've
found that a setting from 40 to 60 is about right
on most systems. The largest number of buffers
that can be allocated is 99.
3. COUNTRY=xxx
This parameter specifies how the keyboard is
mapped, the currency symbol, the decimal
separator, and most importantly, the date and time
formats.
WARNING!!! OPUS WILL DO NASTY THINGS IF THE
DATE FORMAT IS NOT AMERICAN!!!
OPUS Sysop Manual - Page 6
You can still load an optional keyboard driver,
but you cannot specify a country code other than
001. If you are experiencing dates showing up as
garbage, you have your machine installed for the
wrong country, even if you live there.
4. DEVICE=ANSI.SYS
You must include this statement in any Config.sys
file that will be used when an OPUS CBCS system is
used. There are many enhanced ANSI drivers
available, and some of them might even work.
However, ANSI.SYS is the only currently supported
driver.
If you need help in setting up a Config.sys file, refer
to the configuration section of your DOS manual.
Actually, there is a very good description in the DOS
3.x manual and should more than answer any questions.
AUTOEXEC.BAT
OPUS also requires a couple of things installed in the
Autoexec.bat file on your system. This is usually the best
place to install one-time options and resident programs.
Generally speaking, bulletin boards do NOT get along well
with memory resident software such as dPath or Ready!
Anything that installs its own keyboard routines will often
cause conflicts with the routines for the bulletin board.
You can try to use whatever programs you want with OPUS, but
there is no guarantee that they will work. If you are
experiencing strange problems with OPUS, uninstall any
memory resident programs, and see if the problem stops.
OPUS!Comm
The low level communications routines that OPUS uses are
contained in the OPUS!Comm program. This is a memory
resident assembly language program that was specially
designed for OPUS. It supplies all the routines for
transferring information from OPUS to the modem. Because it
is memory resident, it should only be run once, and is well
suited to being installed in the autoexec file. Simply call
OPUS!Comm from the autoexec file, and forget about it.
If you are running other memory resident programs, you may
experience some difficulty with OPUS!Comm. You can try
installing OPUS!Comm last and that may solve the problem,
but it is NOT guaranteed.
Also, OPUS!Comm is a superset of the communications driver
used by SEADog<tm>, which is an extension of the routines
OPUS Sysop Manual - Page 7
used in FIDO<tm>. As a result, SEADog<tm> will recognize the
OPUS!Comm driver and use it instead of its own routines.
This will save you a few bytes of memory if you run
SEADog<tm>.
Set TZ=
Internally, OPUS always works in Greenwich Mean Time. You
rarely are exposed to this. OPUS tries to adjust to your
time zone using a DOS environment variable called TZ. This
is a standard practice for programs written in Lattice or
MicroSoft C and you may already have this set correctly if
you are a C programmer. If not, you will need to calculate
the difference in time between your time zone and Greenwich
Mean Time. This is not really that difficult and you can set
it once and forget about it. We have some examples for the
US, but you're on your own if you are overseas. The format
for the variable is xxxyyy where xxx is the three letter
designation for your time zone (I.E. EST for Eastern
Standard Time), and yyy is a two digit signed number
signifying the difference from Greenwich Mean Time to your
time zone. Countries west of Greenwich will have a positive
number, and those to the east will have a negative number.
The sign is required in the definition. Here are the
examples for the United States:
Eastern
For standard time.......... SET TZ=EST+05
For daylight time.......... SET TZ=EDT+04
Central
For standard time.......... SET TZ=EST+05
For daylight time.......... SET TZ=EDT+04
Mountain
For standard time.......... SET TZ=EST+05
For daylight time.......... SET TZ=EDT+04
Pacific
For standard time.......... SET TZ=EST+05
For daylight time.......... SET TZ=EDT+04
OPUS defaults to Central Standard Time which is CST+06. If
you are in the central time zone of the U.S., you don't have
to set this, although it is still a good idea.
OPUS Sysop Manual - Page 8
Functional Overview
OPUS-CBCS is a conversational tool that supports several
different types of information transfer. A few notes about
nomenclature might be in order here.
The Matrix
The Matrix is the OPUS word for network. This was
chosen instead of network due to the ambiguity
associated with the word network in a FIDONet<tm> sense
of the word. It is the Matrix which gives OPUS its edge
over other <tm> bulletin board systems. The Matrix is
defined as being a group of bulletin boards to which
calls can be made to transfer information. OPUS itself,
as of this writing, cannot place outgoing Matrix calls,
although it is able to receive incoming mail from
FIDO<tm> and SEADog<tm> systems at any time. You may
use FIDO<tm> v11w or SEADog<tm> 3.82 or compatible mail
programs in order to place outgoing calls from an OPUS
system. OPUS incorporates provisions to use either of
these packages for originating mail. As of this
writing, OPUS is compatible with SEADog<tm> 4.0 (Yet to
be released), but no guarantees can be made about
FIDO<tm> v12, because the author has no information on
interfacing to it.
Messages
Messages can basically be of three different types, or
scopes. These are defined as local, network, and
broadcast. Depending on the scope, a message will
behave differently on an OPUS based system.
Local Messages
Local messages are the simplest form of message
available. Almost all BBS systems have this type of
messaging system. Local messages are available to a
predefined group of users, but only upon the BBS that
they were entered. They will not be marked to be sent
to another BBS system.
Matrix Messages
Matrix messages are marked for transmission to a remote
system or group of systems. OPUS cannot directly send
the message, but the message format is compatible with
existing <tm> network mailers, and fully supports the
SEADog<tm> network extensions. This type of message is
good for sending a note to a user or sysop in a
different area. These types of messages can be used to
OPUS Sysop Manual - Page 9
send files and request files, both on a scheduled basis
or as immediate priority. The latter requires the use
of a SEADog<tm> mailer.
Broadcast Messages
Broadcast messages are fully compatible with EchoMail.
EchoMail, by Jeff Rush, it is a means of maintaining
the same message base on multiple bulletin boards. This
allows conferencing on an international level if you
choose to do so. Remember, any Matrix associated, or
broadcast message still requires that you make
arrangements to transfer mail via an external mailer.
Also, phone calls placed for mail transfers cost the
same as regular calls. You need to be aware that
anything involving Matrix transactions will cost you
money to run.
File Section
File transfers can be of three different types.
Uploads, Downloads, and Matrix file transfers are all
supported in OPUS. These protocols allow you to share
software with your users and other bulletin board
systems.
Uploads
Uploading is defined as a user sending a file to the
BBS system. This allows users to share programs that
they have written or collected with other users of the
bulletin board. Several transfer protocols are
supported in OPUS. These include Xmodem, Ymodem,
Telink, SEALink<tm>, Windowed Xmodem, and Sliding
Window Kermit. These will be described more thoroughly
in the file transfer section.
Downloads
Downloading is defined as a bulletin board system
sending a file to a user. This allows a single point to
serve as a 'holding tank' for software that can be
freely shared among users. The same transfer protocols
are available for download as for upload.
Matrix
Matrix transfers can either be uploads or downloads,
but this works between two Matrix BBS systems. In other
words, you can direct OPUS to mark a message as Matrix
with a file attached, and the external mailer program
will send that file to the specified system. OPUS will
OPUS Sysop Manual - Page 10
accept incoming Matrix files any time the program is
running.
Operating Philosophy
The operational philosophy of OPUS can be summed op in a
very brief statement:
KEEP IT SIMPLE!
OPUS is very easy to use when you let the installation kit
do its job. A sysop can lead a very satisfying life with the
basic OPUS installation. It will still be a superior system,
and will require a minimum of maintenance. There are
thousands of custom features available; each OPUS board will
probably look and act differently, but there is no guarantee
that any of the customization methods will be easy or
immediately apparent. It's best for the novice sysop to run
a basic system and to gradually start customizing things as
he/she gains experience with OPUS. That's what we suggest.
The difficult functions are always available, but never
required. If you want to tailor your system to look and act
in just a certain way, you can at any time. However,
remember the rewards you reap are proportional to the amount
of work you put into the system, and that can run into man
years if you choose for it too.
Differences Between OPUS and FIDO<tm>
OPUS is NOT a FIDO<tm> "clone"; it doesn't always try to
mimic FIDO<tm> operations. The only compatibility between
OPUS and FIDO<tm> involves the structure of the support
files. For example, if you are currently running a FIDO<tm>
system, then you can expect all of your "*.BBS" files to
work with OPUS. That includes such text files as Dir.Bbs,
Welcome1.Bbs, and so forth. It also includes the data files
like User.Bbs, and Mail.Sys.
There is no guarantee of compatibility beyond OPUS version
0.00. If file structures change, however, you can expect to
see conversion programs to let you go back and forth between
structures.
File Structures
This section describes some of the major differences in file
structure between OPUS and FIDO<tm> v11w, and some of the
enhancements in OPUS.
The menu files have the same structure, however the contents
of the menu files are very different. You must never attempt
to operate OPUS using FIDO<tm> "*PRIV.BBS" files or vice
OPUS Sysop Manual - Page 11
versa. All of the menu editing programs that are designed to
work with FIDO<tm> "*PRIV.BBS" files will work with OPUS
because the structures of the files are the same.
The first character of each menu option does NOT have to
remain the same in OPUS. OPUS is sensitive to the relative
record position rather than any particular character. For
example, if the third menu option is "M)essages", then OPUS
doesn't care if you rename that to "N)otes". The third
option would, in this example always get you to the message
section regardless of what its name showed.
Although OPUS understands the embedded signals for FIDO<tm>
questionnaires, we recommend that you modify any
questionnaire files to use OPUS embedded commands. This
compatibility will probably be the first to go.
OPUS defines two additional access levels:
ASSTSYSOP - between Extra and Sysop
HIDDEN - above Sysop (mainly to make
unused menu items invisible)
Extended Display File Capability
ANSI graphics are supported as an option to the user. Each
support file has two flavors: Text and Graphics. These are
differentiated by extension in that text files have an
extension of BBS, and graphic files use GBS.
Through the use of an embedded command, you can have any
support file branch to an external program. The sysop is
responsible for insuring that the program directs its output
through the comm port. This feature allows multiple
"Outside" features to be supported.
Questionnaire information can be collected from within any
BBS/GBS file. This can be used to log the activity of any
displayed section of your board.
You can insert a person's name, display a quote, date and
time displays, etc within any BBS/GBS file. Virtually
anything OPUS knows about the user can be displayed at any
point in the support files.
Additional embedded commands allow you to make any BBS/GBS
file a submenu. This is handy for things like multiple
bulletins, interactive help systems, etc. For a complete
list of embedded commands see Appendix D.
OPUS Sysop Manual - Page 12
Extended File Transfer Protocols
OPUS includes provisions for a variety of transfer
protocols. These include Xmodem, Ymodem, WXmodem, Telink,
SEALink<tm>, and Super Kermit. This allows virtually any
computer system to transfer program files to and from the
bulletin board.
EchoMail Enhancements
OPUS allows the sysop to determine whether EchoMail SEEN-BY
lines are displayed to the user. Most people complain about
the unsightliness of this part of EchoMail, and OPUS
eliminates that problem. If you do not care about SEEN-BYs
at all, OPUS allows you to disable their display.
Extended FIDONet<tm> addressing display can be disabled. As
more distinct addresses become available over the Matrix,
there will be a need to embed more information within the
body of a message. OPUS allows you to control who can and
can't see this information.
OPUS automatically inserts its own origin line if a message
area is marked as broadcast. This allows other systems to
know what package processed the mail.
You can tell OPUS to automatically unARC and toss incoming
EchoMail packets. In other words, when an incoming message
has an ARCmail packet attached to it, you can tell OPUS to
take care of placing it in the appropriate areas. You no
longer have to declare an external event to extract ARCmail
packets and toss EchoMail. OPUS does this for you.
NOTE: These features require that you have all your message
areas on the same physical drive. Unpredictable results will
occur if this is not the case.
Mail Interface
OPUS has the ability to receive FIDONet<tm> compatible mail
packets at any time. This means that Matrix transactions do
not necessarily have to run at any given time. You send your
mail to an OPUS at whatever time is convenient for you. OPUS
messages are completely compatible with FIDONet<tm> and
SEADog<tm> specifications. Even though it cannot place
outgoing phone calls, OPUS allows any message entered on the
system to be handled by a FIDONet<tm> compatible external
mail program.
OPUS Sysop Manual - Page 13
Extended Message Area Attributes
A variety of message area attributes are supported. You can
define exactly what type of messages will be placed in what
area.
Areas may be marked as being private only. This means that
all messages entered in this area will be marked as private,
and cannot be read by other users.
Areas may be marked as public only. This will require the
users to enter messages that can be read by any other user.
OPUS supports anonymous messages. If an area is marked as
being anonymous, OPUS will ask the user for the name that
they want the message to be from.
EchoMail message bases are recognized. The user will be told
that the message will be broadcast, and OPUS automatically
inserts the Origin line.
Matrix messages are treated like FIDONet<tm> messages. The
user is asked where the message is to be sent and to whom.
Message areas can be marked as being Barricaded. A barricade
is a file that defines legal passwords for that area.
Passwords have a privilege associated with them, and using
this feature you can allow people higher privileges within
certain areas.
Any of these attributes may be combined in any fashion. You
can require all messages in your Matrix area to be private,
or all EchoMail messages to be public. It is totally up to
the sysop as to how message areas will behave.
Message Area Commands
OPUS adds four new commands to the message section, and one
new command to the Matrix area menu. These allow you to do
several things that FIDO<tm> does not allow.
F)orward allows you to redirect a message to another user.
This comes in handy when a user has entered a message to the
wrong person. You can respecify who that message is sent to.
F)orward has another variation called Forward as Bombing
Run. This allows you to forward a message to a predefined
list of people without having to reenter the message
multiple times.
H)url can be used to move a message from one area to
another. You can move messages to the appropriate area if a
user doesn't understand the system. This also works very
OPUS Sysop Manual - Page 14
well for removing advertisements from EchoMail areas.
NOTE: This requires all your message areas to be on the same
physical drive. Unpredictable results will occur if you try
to hurl a message to a different drive.
=)Read non-Stop does just what it says. It will continuous
display messages until the highest message is reached. The
user may open a capture buffer, go into a message area, and
essentially download an entire group of messages for reading
offline.
S)can will check for messages to the user in ALL message
areas. There are several programs available that will create
a file listing pending messages for a user. With this
feature, the user can do this at the time he/she logs on.
OPUS does not have a read message menu like FIDO<tm> does.
All the commands for message areas are contained in one menu
making message functions much easier to manage.
In the matrix area, you have the ability to manage more than
one list of Matrix addresses. FIDONet<tm> is in the process
of implementing this by adding an additional level of
network called Zone. This is the highest group and
FIDONet<tm> defines these by country. OPUS uses a different
approach. When you choose Z)one from the Matrix area in
OPUS, you are really deciding on which nodelist OPUS will
use. You can have as many zones as you choose. They can be
grouped by country, continent, or however you want.
In OPUS, the message editor commands are contained in a menu
file. It works like any other "*PRIV.BBS" file and allows
the system operator to set access levels for the various
commands.
The LORE (line-oriented editor) has an additional command:
H)andling. It lets you manually change the attributes of a
message. Current attributes consist of Private, Kill/Sent,
File-Attach, Crash, File-Request, Return-Receipt Request,
Update-Request, and Audit-Request. Some of these attributes
are for use with external mail programs, and have no real
use when sending mail to another OPUS system.
File Area Commands
Two new file area commands are added. H)url and O)rphan.
H)url works for files just like it does for messages.
O)rphan allows you to place entries in the file list for
files that are in the directory, but not in the file list.
OPUS Sysop Manual - Page 15
Miscellaneous Commands
The user is not required to hit the return key when he/she
logs on to establish a baud rate as he/she does in FIDO<tm>.
OPUS does this automatically.
ARC and LBR file contents can be displayed. The user can see
what files are contained in an ARChive without downloading
it.
OPUS checks to see that a user exists on the system when a
user addresses a private message to him. This insures that
every message is receivable. This function is disabled in
Matrix and EchoMail areas because these areas imply that the
person the message is addressed to is not a user of the
local board.
All of the Sysop commands are menu driven in OPUS. This
makes board maintenance much easier.
The Sysop can either raise or lower a user's time and or
access privilege from the local console.
OPUS Sysop Manual - Page 16
THE MESSAGE SECTION
What is a Message Section?
Messages allow users to record notes to each other while
they are online. This allows questions to be answered and
conversations to be held between different users and the
sysop. Opus implements this in a variety of forms. Messages
can be local to the board or broadcast in a general
conversation, and can either be public or private. These
messages are grouped by category, with a separate
subdirectory for each topic on your hard disk. You can have
your messages grouped however you want them. The directory
structure allows you to manage messages in an orderly
fashion. You can define many things about message areas
including who can see them, who can enter them, whether they
are 'broadcast' or not, and whether they can be deleted.
Setting up a Message Section
System Files
Each category, or area is referred to by its own number and
has its own separate configuration file that allows the
sysop to define the manner in which it will be used. These
files are named as 'SYSTEM??.BBS', where "??" stands for the
area number. Valid system area numbers are 1 thru 99. Each
area is a separate subdirectory, and has unique
characteristics. These include location, description,
support, and privilege.
Creating a System File
Select "!" at the main menu to access the Sysop menu. From
this menu you should choose A)rea maintenance. This menu
always defaults to the main system menu, or area 0. This is
the primary configuration for OPUS. It defines where the
main help files are located, and where messages left at
logoff go. Generally, you will not use the other options for
the primary area, and you will set its access to Sysop.
To create a new message area, select A)nother area from this
menu. Pick a number that is one higher than your highest
system file. If you have used the installation kit, you
should pick three. OPUS will tell you that there is not an
area three, and will ask you if you want to create one.
Select yes, and you will see the area configuration menu.
The following is a description of each of the items of the area
configuration menu. You can set these options as you please, OPUS
does not restrict area configuration in any way.
OPUS Sysop Manual - Page 17
Privilege
This option allows you to set the minimum privilege required
for this area to be available to the user. Using this
feature allows you to restrict usage of a message base to
the people you have authorized. There are currently eight
access levels:
TWIT
DISGRACE
NORMAL
PRIVIL
EXTRA
ASST. SYSOP
SYSOP
HIDDEN
This allows you to set general access restrictions for a
message base. You could have a general message base assigned
a privilege of normal, and a private area devoted to your
close friends defined as privil, and be assured that the
private conversation would remain that way. See the Access
Level description in the Sysop section later in this manual
for more details on privileges.
Setting Paths
Most of the rest of the configuration section involves
setting the DOS pathnames to the various support files. We
do not intend to provide a tutorial on DOS. You should know
enough about that already. We will give you a little
background about the way OPUS treats pathnames. First, OPUS
requires all paths to be fully qualified. That is, you must
specify drive and subdirectory in each of the following
items. If you don't, OPUS will tell you about it, and you
will have to reenter the path. This is done to insure that
all the information is absolutely where OPUS can find it.
This also holds true in the control file though the compiler
will not be so forgiving. More on that later on.
Second, OPUS requires all paths to end in a trailing "\".
Just to keep you on your toes, OPUS automatically puts this
in for you in the system file configuration, but does NOT in
the control file. When you are dealing with OPUS in an
interactive mode, I.E. from the "!" menu, you do not have to
enter trailing backslashes. All paths specified in the
control file must have them. Got it???
BBS Path
The BBS is the path to the privilege files to use for this
area. Privilege files allow you to define which menu
OPUS Sysop Manual - Page 18
commands are available to the user. Even though a user has a
high enough privilege to access an area, he/she will not see
the menu options that are set to a higher access level than
his. Setting the privil files is discussed later under sysop
commands.
*** For Advanced Users***
You can have several sets of priv files
contained in different subdirectories. This
allows you to set two areas to access the
same message base with different privileges.
This allows you to give several people
extended privileges within certain areas, by
accessing different area numbers. Think about
it.
Help Path
This allows you to specify the path to the help files for
this area. These files are displayed when the help key (?)
is pressed at the menu for this area.
*** For Advanced Users***
Theoretically, you can display different help
files for each area, but this is not
generally used.
Message Path
This is the DOS path to the actual messages. This can be any
valid DOS directory, and will be the storage place for the
messages. When you initially set this path, OPUS will report
that it cannot find a file called "DIR.BBS" and ask you if
you want to create one. If you answer no to this question,
you cannot use the T)itles option described below, and you
are on your own to create this file.
File Path
This is the corresponding file area. See the file section
for a description.
Titles
Each side of the area has a title that the user sees. This
is the topic or category, and is maintained in the file
'DIR.BBS' in the appropriate subdirectory. OPUS allows you
to modify the contents of this file from the area
maintenance menu. It generally consists of a one line
description of the contents of the area. This description
OPUS Sysop Manual - Page 19
will be displayed immediately above the menu and when the
user chooses A)reas unless the sysop has configured OPUS to
use Msgareas.Bbs. (See the installation gude for further
details).
Area Types
There are three basic area types for messages: Local,
Matrix, and EchoMail. These determine the way a message is
handled by Opus.
Local
Messages that are tagged local will only appear on the BBS,
and will not be seen by users of another bulletin board
service. These can be either private or public, and can have
anonymous names, but will only be recorded on the computer
the user is talking to when the message is entered.
Matrix
These messages are sent through the matrix, that is, they
are generated in one city, and are sent to another single
city. This is the equivalent of a letter. The user decides
who it will be sent to, and where they live, and your board
will generate a message that is compatible with an external
mail program that can deliver the message. Naturally, you
can define the users who can send mail to other users via
the Matrix. This is discussed under the Mail section.
EchoMail
This is a means to share message bases between several
boards. It allows you to create conferences that are shared
between different parts of the country. EchoMail is not
free. It still costs you the charge of sending a message to
the Echo connection, but it generally allows conversations
at a greatly reduced cost. Opus supports EchoMail internally
for reception; it is up to the sysop to maintain a means of
sending mail to another system.
EchoMail uses several programs to link Opus to an external
mail processor for managing EchoMail areas. See the related
EchoMail documentation for details on how to participate in
EchoMail. Opus provides direct support for incoming mail,
and subsequent EchoMail processing. Therefore, the sysop is
freed from the task of implementing it in batch files. (See
the echomail special considerations section.)
OPUS Sysop Manual - Page 20
Area Aspects
The aspects you set for an area determine the way messages
behave within that area. You can customize aspects to allow
users to only read, only post public messages, or to allow
them to post anonymous messages. Once again, OPUS leaves
this entirely up to the sysop.
Privilege Levels
The privilege you assign an area determines the users that
can access that area. This allows you to determine which
users can read certain areas. Privs are downwards inclusive.
This means that any user can access areas of his priv or
lower. For example, you have set up four areas, two set to
normal, one set to privil, and one set to extra. A user with
normal privilege will be able to access the first two areas.
A privileged user will be able to access the third area as
well as the first two, and an extra user will be able to
access all four areas. Privilege levels are the most general
type of area aspects.
Public-Only
Message areas can be marked as being public-only. This will
eliminate the question as to whether or not a message should
be marked private. All messages entering in a public-only
area may be read by any user.
Private-Only
You can mark a message area as being private only also. This
will automatically tag every message as being private to the
recipient. This is the inverse of the above, and will also
eliminate the "Private?(Y/N)" question. The difference is
that with this attribute, all messages will be private,
while those areas marked with the previous attribute will
contain nothing but public messages.
Public-or-Private
This is the default message area aspect. The user will be
asked whether messages should be marked private, but public
and private messages can be mixed within the area.
Read-Only
This attribute sets a message area to be non-postable. Users
can read messages as much as they want, but they cannot
enter messages. This is useful for general release notes,
mini-bulletins, etc.
OPUS Sysop Manual - Page 21
Anonymous-OK
OPUS allows the user to enter the name to be used in the
from field if this attribute is set. Normally, the users
name is used in messages. You can use this to allow users to
enter a pseudonym instead of their name when they enter a
message. This is used mostly in EchoMail areas where many
users discuss things.
Special Considerations for Matrix Messages
Although any of the above settings can be used in a Matrix
area, it is generally not a good idea to change this area to
allow anything other than normal messages. When OPUS creates
a new system file, it defaults to being public and private
messages, with no additional attributes. All that is
necessary here is to add the Matrix attribute to the list,
and you are ready to go. The other options that are
configurable in a Matrix area are set within the control
file.
NetInfo
The first option in setting a Matrix area is the NetInfo
path. This tells OPUS where to find the FIDONet<tm>
compatible nodelist. The syntax for the statement is:
Path NetInfo d:\(path)\
where d: is a logical drive on your system and (path) is the
subdirectory where you intend to keep the nodelist. OPUS
itself cannot maintain this nodelist. To keep this list up
to date you must use a utility such as OPUSnode, or
Xlatlist. OPUSnode is included in the distribution kit and
you should refer to the documentation with it for more
information on maintaining nodelists.
OPUSnode
OPUSnode is an external nodelist compiler that allows you to
create nodelists that are compatible with FIDO<tm>,
SEADog<tm>, and OPUS. Without a nodelist, you cannot send
Matrix messages with any of the external mailer programs.
See the OPUSnode documentation for details on usage and
syntax.
Cost Accounting
Because sending Matrix messages to a remote system can
involve making long distance phone calls, OPUS maintains
accounting information in the user file just like FIDO<tm>.
If a user does not have enough credit to place an outgoing
call, he/she cannot send any Matrix messages. You can use
any of the external user file utilities that are compatible
with FIDO<tm> v11w user file structures to set a users
OPUS Sysop Manual - Page 22
credit. We recommend using REMSYS20, by Bernie Lawrence. It
understands all of the extended OPUS attributes and can be
run either from the local console, or through the modem.
You can set a multitude of options about the Matrix area. These
are all contained in the control file. The best documentation for
the control file is the sample file contained in the installation
kit. It was written by the author and is the definitive source
for setting the control file options. This section only covers
the options that relate to the Matrix area.
Handling Crashmail
A large portion of the Matrix configuration involves
specifying how OPUS handles incoming mail. This section
describes each of those options.
Refuse Crashmail
You can keep OPUS from accepting incoming mail. This is
useful if you are not a member of the Matrix. If you do not
belong to any Matrix group, you should include this in your
control file:
MATRIX Refuse Crashmail
After Crashmail Exit
After OPUS receives mail, you can exit the program with a
DOS ERRORLEVEL set. This is for those who need to do special
message/file processing after an incoming packet. The most
obvious use is EchoMail's Scan. This is accomplished by
including this line in the control file:
MATRIX After Crashmail Exit xx
where 'xx' is the DOS ERRORLEVEL you wish to exit OPUS with.
The sysop is responsible for trapping this errorlevel and
taking the appropriate action in the batch file.
IFNA<tm> Kludge
The International FIDO<tm> Association has devised a means
for systems using their amateur e-mail network to pass
extended control information with other programs. This is
mostly extended addressing information for international
mail and auditing information that tracks the processing of
mail. You can set the privilege level of users that can see
this extended information. Setting this priv to HIDDEN will
prevent OPUS from displaying this information at all. The
syntax for this statement is:
MATRIX Kludge <priv>
where <priv> is any valid privilege level (See Privilege
Levels above).
OPUS Sysop Manual - Page 23
Extract ARCmail
ARCmail is an external mail packeting program created by
System Enhancement Associates. It is commonly used in the
processing and transfer of EchoMail. When ARCmail is crashed
to your board, you can tell OPUS to automatically extract
the compressed packets. If you use this feature, the program
ARCE.COM must be available on your DOS path. ARCE is not
OPUS software, and it is not supplied with this system. To
use the automatic extraction feature include this in your
control file:
MATRIX Extract ARCmail
If you do not have enough memory to run ARCE, see the sample
control file for an example of how to do this by exiting
OPUS after an incoming mail packet.
After ARCmail Exit
This is a special variation of the "After Crashmail Exit"
option. The statement for this is:
MATRIX After ARCmail Exit xx
where 'xx' is once again a DOS ERRORLEVEL.
Default Settings
You can also tell OPUS what defaults to use for a message
entered in the Matrix area. This includes things like
private, kill/sent, etc. This allows you to specify exactly
what a user can and cannot do with a Matrix message. There
are two groups of configuration options here: Assume and
Ask. If the attributes are not either assumed or asked, they
are ignored. The sysop can always override these default
settings using the H)andling option.
MATRIX Assume vs. MATRIX Ask
Assumed attributes are automatically set for messages
entered in the Matrix area. Some of them will only work if
you are using SEADog<tm> for your external mailer. The user
does not have to do anything to set assume attributes, OPUS
takes care of it. On the other hand, setting Asked
attributes will make OPUS ask the user if he/she wants to
set this attribute when the message is entered. Some
attributes are more suited to Assume while others are better
off being asked. For example, Kill/Sent is better off
assumed as it generally confuses the user. The syntax for
these commands is:
MATRIX <verb> <attribute>
where <verb> is either Assume or Ask, and <attribute> is one
of the below.
OPUS Sysop Manual - Page 24
Kill/Sent
This attribute tells the external mailer program to delete
the message after it is sent. A Matrix message is addressed
to a remote bulletin board and is generally of no use once
it has been successfully sent. Specifying this option will
help keep your Matrix area tidy and decrease the amount of
time your external mailer takes to process messages.
File Attach
Specifying this option will make OPUS ask the user for the
name of a file to be sent to the remote system.
WARNING!!! In this version of OPUS, file
attaches can be from any valid path on your
system. If you set file attach to ask, the
user can send ANY file on your system to
another system, where it can be publically
downloaded. In future versions, this will be
keyed off of a privilege level, and will
incorporate some protections, but not yet. DO
NOT SET FILE ATTACH TO ASK IN OPUS 0.00!!!
If File Attach is not asked, the user cannot send a file to
a remote system. The system operator, on the other hand, can
get around this limitation by specifying the full path and
name of the file to be sent as the subject, and using the
H)andling command set the file attach bit.
The rest of the message attributes will only work if you are
using SEADog<tm> as your external mailer. SEADog<tm> and OPUS use
a superset of the FIDO<tm> attribute specifications. FIDO<tm>
will ignore any of the attributes listed below. This is a brief
description of some of the extended attributes available with
SEADog<tm>. See the SEADog<tm> manual for a more verbose
description of these attributes.
Crashmail
Crashmail is defined as mail to be sent at any time of the
day. OPUS can accept mail 24 hours a day if you so choose.
It can also be used as the bulletin board under SEADog<tm>.
If you implement the system this way, you can both send and
receive mail all the time.
File Request
You can tell OPUS to set the attribute for the message to
file request. This tells the system that receives the
message to send the requested file back to your system.
OPUS Sysop Manual - Page 25
Update Request
An update request is similar to a file request except that
the file will only be sent back if it is newer than the one
that you already have on your system.
Return Receipts
If you specify a return receipt, the remote system will send
you back a message telling you when it received the message,
and whether or not the transmission was completely
successful. This is very useful when the system you are
calling is known to have bad phone lines, or you are making
an overseas transmission. If your external mailer program
uses routing, you may get nastygrams back from the host of
the remote system. Some sysops do not like having to spend
the money to deliver receipts.
Audit Trail
Audit Trails can give you very tedious details about the
route a message or file took between your system and the
remote system. As with return receipts, other sysops
generally dislike having to make phone calls to give you
this information.
You can set any or all of the extended attributes if you are
using FIDO<tm> as your mailer program. Some of the attributes
will be passed on, mainly the request and receipt functions. This
allows you to get some of the functionality of SEADog<tm> without
having to purchase it!
Special Considerations for EchoMail
OPUS supports incoming EchoMail directly. That means that you can
use OPUS instead of ARCmail and TossMail to process mail you
receive. In most cases, OPUS processes incoming mail much, much
faster than the external programs. Of course, this may not be
true for your system as it depends greatly on the hardware you
are using.
Configuration Note
All of OPUS' EchoMail support depends on you setting all
your message areas up on the same logical drive. If you
spread message bases between several drives, DO NOT attempt
to use these features! Unpredictable results will occur.
Areas.Bbs
In order for OPUS to process your EchoMail, it has to have
the EchoMail support file "Areas.Bbs" in the path specified
OPUS Sysop Manual - Page 26
by NetInfo. If this file does not exist in the path
specified by NetInfo, OPUS will not handle EchoMail
directly. You can still use the external EchoMail programs;
OPUS will just ignore any references to EchoMail support.
Origin Line
If OPUS finds your Areas.Bbs file, and a message area is
marked as being an EchoMail area, OPUS will automatically
insert an Origin line at the bottom of the message when a
user saves a message. This origin line is fully compatible
with EchoMail version 1.3?. The difference is that it will
say "OPUS" on that line to differentiate OPUS from other
EchoMail systems.
Automatic Toss
You can configure OPUS to automatically process incoming
EchoMail. (See the Extract ARCmail section for that half of
the process) OPUS can do all the functions of TossMail if
you tell it to. To do so, you should specify the following
line in the control file:
MATRIX Toss EchoMail
Once you've done this, OPUS will process incoming EchoMail
with no further intervention required. You basically set it,
and forget about it.
Seenby Displays
OPUS will suppress the display of EchoMail SEEN-BY lines if
you tell it to. EchoMail uses these lines to determine which
boards have already received a copy of a message. Sometimes
the seenby line is longer than the message, though. Much
like the IFNA<tm> kludge, this is primarily an internal
function, and can confuse the user. If you set this option
to HIDDEN, you will never have to see a seenby line again.
You can set the privilege level that will see seenby lines
with the following line in the control file:
Echo Seenby <priv>
where <priv> is any valid user privilege (See Privilege
Levels above).
Processing Outbound EchoMail
At the time of this writing, OPUS does NOT support the
processing of outbound EchoMail. This will be covered in
later releases of OPUS. You can use whatever is convenient
to you to achieve this externally. Generally, you will have
to implement the following somewhere in an external event if
you are using Jeff Rush's EchoMail and SEA's ARCmail
programs:
OPUS Sysop Manual - Page 27
SCANMAIL RUN
ARCMAIL TO LIST AREAS.BBS
(See the E)vents section under the sysops commands later in
this document for details on how to do this with OPUS, or
the manual for your external mailer program).
Enhanced Message Area Commands
As mentioned previously, OPUS provides three additional commands
above and beyond those provided in FIDO<tm>. These commands are
primarily for use by the sysop, but can be configured to be
available to whatever level of user the sysop wants. They are
standard menu entries and can be set to any privilege using the
"!" (sysop) menu, or can be changed by any FIDO<tm> compatible
menu editor. You can allow first time callers to have access to
these commands, but it is not recommended. Generally, you will
want these commands to be available to sysops and co-sysops
exclusively. (See the P)riv section under the sysop commands
later in this document for details on setting menu privileges)
The Hurl Command
This command allows you to move a message from one area to
another. This is very similar to the M)ove command in the
Mail interface for SEADog<tm>. It will copy a message from
one area to another taking into account the number of
messages in the destination directory. In other words, a
message you hurl will end up being the highest message in
the directory you move it to. You specify the destination
directory by number.
The Forward Command
Forward allows you to change the recipient of a message. You
can respecify the addressee of any message. If the message
is in the Matrix area, OPUS will ask you for the network
address again.
Forward With Bombing Run
This option is accessed by entering 'FB' at the menu prompt.
This allows you to send the same message to a group of
people. This group is specified by a text file. The name and
location can be anything you wish, but you have to tell OPUS
exactly what it is you want to do with this command. In
other words, you probably should specify the full path and
filename when using this feature.
Also, OPUS is not particularly bright about the contents of
the bombing run file. It has a very specific format, and if
you do not follow that format EXACTLY, OPUS will try to
OPUS Sysop Manual - Page 28
follow your instructions, and will make a very large mess of
the entire affair.
The format for the bombing run file is as follows:
The beginning of each line starts with the
address destination in the format of net
number, followed by a slash, followed by the
node number. After the address, you enter ONE
and ONLY ONE space, followed by the name you
want the message to be addressed to. The name
field follows the format of the standard
FIDONet<tm> nodelist. I.E. Underscores
instead of spaces. You MUST use underscores
instead of spaces. For example, a bombing run
file would look like this:
100/10 Joe_Blow
103/12 Henry_Ford
etc....
The Zone Command
In the Matrix area, there is a special new command called
Z)one. This allows you to specify the nodelist to be used
for Matrix addressing. This defaults to the nodelist
specified in the control file, but by using this option, you
can specify which of several lists OPUS will use to find the
Matrix address. If a user has enough credit, he/she can
instruct your system to place a call to Hong Kong, or
Australia, or some place equally expensive. This allows you
to strip out all international addresses and only let
continental mail be sent. Currently, FIDO<tm> has reached
the limits of its nodelist handling capabilities, and is
simply ignoring network addresses higher than the maximum it
understands. OPUSnode allows you to break the nodelist into
several discrete sections for use with your external mailer
program.
NOTE: Z)one is an internal command to OPUS.
The sysop is responsible for insuring that
the external mailer can understand the Matrix
address that OPUS puts in the message. If
this mailer is FIDO<tm>, you probably will
not be able to do much with the capability to
address multiple nodelists. If it is
SEADog<tm>, then there is not much point in
using this feature. OPUS supports the Zone
designation in this manner primarily for
future extensions to the OPUS mail interface.
OPUS Sysop Manual - Page 29
Special Message Areas
There are two additional types of message areas supported in
OPUS; Hidden and Barricaded. This allows you to create areas
that only certain users can access WITHOUT allowing them a
higher privilege, and to allow extended privileges within a
certain area. The variations on this idea are countless.
This will provide many different security levels to be
configured without any additional work for the sysop.This is
a VERY advanced concept and should be explored by the novice
sysop gradually.
Hidden Areas
During the develpment of OPUS, we came across a quirk that
has proved very useful. No one really thought it out; it
just happened. Since then, this has become one of the most
popular aspects of running an OPUS system.
You can define a system file that is more than one higher
than the highest existing system file. I.E. you can have
areas 1 thru 10 and 20. Area 20 will be an area that acts
exactly like any other area, but it will not show up for the
user in any list. Valid area numbers for Hidden areas are 1
thru 49. The "Hidden" areas are a low security means to keep
the general public from accessing an area. The user must
know that the area exists to get there, but if he/she
randomly types the area number, there is nothing to keep him
out of that area. You will find that as OPUS becomes more
popular, users will try to access each and every area in an
attempt to read areas they are not authorized to read. Its
not that every user out there is a "black hacker magician";
they are naturally curious, and will explore any possible
combination of commands they can think of. This is why OPUS
provides Barricaded areas.
Barricaded Areas
Barricaded areas use a separate configuration file to define
the password and privilege a user will have in that area.
Even if a user randomly chooses the area number for a
arricaded area, they will still have to know a password
before being allowed entry to that area. Valid Barricaded
area numbers are 50 thru 99.
When you create a system file higher than 50, OPUS changes
the BBS path to Barricade path. This is the fully qualified
path designation for a file that contains the barricade
information. You can specify the filename for this file in
addition to the path; it is not hard-coded. As in the
bombing run file, this file must follow a specific format:
OPUS Sysop Manual - Page 30
Each line starts with a password. This can be
any number of characters up to 255, but keep
it reasonable. If you specify much more than
20 or 30 characters, your user may run out of
time before he/she types in the password!
After the password, follows one, and only one
space. Any more or less and the user will not
be able to access the area. The last word of
the line is the privilege descriptor as
described in previous sections. If OPUS
decides that the format of this file is
wrong, or that the user is not authorized to
enter the area, his privilege will be lowered
to the minimum. The only way to recover from
this is to logoff and log back on. Once a
user misstypes the password for a protected
area, he/she will be reduced to TWIT and will
not be able to recover without sysop
intervention.
The password file can contain as many entries
as you like, and you can have multiple
passwords for similar privileges. This is
what an example control file would look like:
abc twit
password normal
additional privil
xyz twit
newpassword extra
oldpassword privil
This file would allow users to enter either
'abc' or 'xyz' as a password to enter that
area with a privilege of twit. A password of
'password' would alow them access at normal,
and 'additional' and 'oldpassword' would get
them privil. We think you get the idea.
The sysop is responsible for informing users what passwords
to use in what areas. OPUS will allow anyone who can enter
the appropriate password access to that area. Barricades
generally are used to allow friends and business associates
extended privileges to certain areas.
The privilege a user gets in a barricaded area is temporary
and only works in that area. This allows you to map a
password protected area to a normal area and designate a
"moderator" for a message area. For instance, system file 3
points to a directory called 'C:\Msgs\Group' and so does
area 51. Normal users can enter area 3 and do whatever users
OPUS Sysop Manual - Page 31
normally do in message areas. You have a password file for
area 51 that gives users who enter a password of 'moderator'
the privilege of sysop. This allows your friend Joe to act
as the sysop within area 3 if he/she enters area 51 and
gives the appropriate password.
Within the distribution kit you will find a file called
TEST.DOC. This quizzes you on details of hidden and
barricaded message areas. You should complete the quiz
and mail it back to one of the info nodes. Ready???
Hints, Tricks, and Sleight of Hand
One of the primary purposes in OPUS is to handle bulletin
board tasks as quickly and efficiently as possible. Every
aspect of OPUS was written with speed as the primary goal.
You will find that it fulfills this goal on its own with the
exception of a couple of areas.
Directory Sorts
OPUS tries very hard to find its configuration files as
quickly as possible. Due to the nature of DOS, this can
still take quite a bit of time unless you help OPUS from
time to time. You will find that OPUS will run much quicker
if you use some utility to sort your directories. Professor
Norton's DIRSORT works very nicely. This has two advantages.
First, by nature, it sorts all directory names to the top of
the directory listing. This allows OPUS to fly through path
finding operations. Second, directory sorting will force
deleted file entries to the bottom of the list. You dodn't
know DOS kept entries for deleted file??? Of course. That's
why when you delete all but one file in a directory it takes
half a lifetime to display a directory.
OPUS can deal with unsorted directories just fine - you just
sacrifice speed. There are many utilities that sort
directories and they improve performance greatly. If you
don't already have one, you should consider finding one.
Renumbering Message Areas
By nature, message areas are not necessarily contiguous. As
a message base ages, messages are either killed by users, or
deleted by date. As this occurs, "holes" are left in the
message base structure. These holes slow down the time it
takes OPUS takes to determine the highest message, and how
quickly OPUS finds the next highest message for viewing. If
you do not periodically renumber your message areas,
eventually, OPUS will spend all its time skipping directory
entries and will never get its work done.
OPUS Sysop Manual - Page 32
Naturally, there are solutions that take care of this
problem. One, RENUM by Bob Hartman, seems to work best with
OPUS. It has several options only one of which we will
discuss here. RENUM will go through a message base and
insure that the highest message number actually reflects the
highest number of message files. In other words, it will
eliminate any gaps you may have in your message base by
changing the higher message numbers to fill in the gaps.
Your messages will still be in chronological order, it does
not rearrange them, it just insures that if you have 100
messages available, they are numbered one thru one hundred.
OPUS remembers the highest message a user has read.
Due to the limitations placed on it by FIDO<tm>
compatibility, OPUS can only maintain high message markers
for ten areas in the user file. FIDO<tm> only maintains
eight. However, OPUS knows that the sysop will mainly be
reading messages from the local console, and uses a
different means to record the highest message read for the
sysop. This involves treating the marker in the fashion
SEADog<tm> uses. Each time you read a message from the
keyboard, a file called LASTREAD is updated in the message
area you are reading. Because this information is maintained
in the same directory that the messages are in, OPUS can
maintain an infinite number of message pointers. If you use
Bob Hartman's RENUM to maintain your message bases you need
to specify '-S' as the first parameter of the command line
to tell RENUM to maintain the LASTREAD files. While
providing support to an unlimited number of areas, this
feature is restricted to one user. If you use another
renumbering program, you need to insure that it takes the
LASTREAD files into account.
Disk Optimizing
Last, but not least, you need to run some sort of
optimization on your disk drives periodically. Because of
the way DOS manages directories, you will end up with an
area that is mostly deleted files. This is especially true
if you use EchoMail and ARCmail. By nature, these programs
generate a whole bunch of messages and then delete them
after moving the information to another directory. DOS still
retains a directory entry for each deleted file. You will
find that the more deleted file entries there are in a
directory, the slower the programs that access that
directory will work. This is especially true of EchoMail and
ARCmail. The slow down is proportional, but not on a one to
one basis. If you have half as many messages to process as
you have directory entries, you should expect to spend four
times the amount of time processing them. This is not quite
so obvious with small message bases as it is with large
ones, but the delay is still there.
OPUS Sysop Manual - Page 33
We have found DOG (Disk OrGanizer) to be a very good
solution to this problem. It has options to allow you to run
it unattended in a batch file, and its Fast option seems to
take care of the problem without wasting a lot of time. On
an eight megahertz 286 based machine it generally takes two
minutes if run daily.
OPUS Sysop Manual - Page 34
THE FILE SECTION
What is a File Section?
The file section of OPUS allows the users to exchange
programs and information contained in files that they create
offline. File sections are treated much the same as message
sections, and configuring them is so similar that we will
only discuss the areas that directly affect the file areas.
Configuring a File Area
You configure the area of your hard drive that will contain
a file section very similarly to the manner in which you
configure a message section. Select the "!" command from the
main menu, and pick A)rea maintenance. There are only three
options here that affect file areas.
Upload Path
The DOS path you specify here is where files that are sent
TO your system will be stored. You can set all your upload
paths to the same subdirectory, or to separate
subdirectories. The sysop is entirely on his own to manage
these files once they are sent.
Download Path
This path specifies where OPUS will look for files that the
user requests to be sent to him. You should divide your
download areas up by type of program. I.E. use one area for
utilities and another for games. You can have up to 99
individual file areas.
Titles
Each file area has a one line description which is contained
in the file Dir.Bbs in the download path. OPUS allows you to
change the contents of this file using the T)itles command.
This description is displayed at the top of the menu when
the user is in a file area. This description will also be
displayed whenever the user chooses A)reas from the file
section menu unless the sysop has configured OPUS to use
FileArea.Bbs. (See the installation guide for more details).
Files.Bbs
The list of files in an area is contained in the file
Files.Bbs in the area subdirectory. OPUS maintains this list
for you for files that are sent to your system. The file is
a standard text file, and can be created with any text
editor that outputs pure ASCII files. The basic format of
OPUS Sysop Manual - Page 35
the file is as follows:
<filename> <description>
with one filename listed per line. Multiple description
lines are supported as long as the first character of each
line in the description is a space.
Comments
Lines that begin with a dash ("-") are used for headers and
important announcements in Files.Bbs. Whenever OPUS sees a
dash as the first character of a line, it changes the screen
color to white if the user has graphics enabled. For normal
comments and multiple line file descriptions, use a space
for the first character of the line. You can place comments
anywhere in Files.Bbs.
End-of-List Character
The end-of-list character is the "@" sign. If OPUS sees this
character as the first character of a line, it will not
display anything in the file after that character. This is
useful for allowing users to upload files into an area
without allowing subsequent download of the file until it
has been checked by the sysop.
Wildcards
OPUS allows wildcards to be included in Files.Bbs. When OPUS
encounters a wildcard in the files listing, it will expand
the file list to include any files that match the wildcard.
If there is a description after the wildcard, it will follow
the last file matching the wildcard that OPUS finds. This is
very useful for maintaining lists of files that are sent to
your system via mail. Because these files are not uploaded
by a user, OPUS does NOT add a line to Files.Bbs signifying
that the file is available. This feature allows you to make
files that are sent to your system available for download
without requiring any maintenance.
Wildcard support is very limited and should be used with
care by the sysop. Files listed with wildcards can only be
downloaded by users that are privil and above, and commands
like L)ocate will not find these files. This is a temporary
limitation and will be changed in future versions.
Handling Dates
OPUS allows the sysop to handle dates in the file lists in
several ways. The sample control file explains this in
greater detail. Suffice to say, if you need Files.Bbs to
contain a date after the filename, OPUS can be configured to
do that for you. However, this will disable the display of
OPUS Sysop Manual - Page 36
new files for the user. Normally, OPUS will display an
asterisk by the file date if the file has been added to the
system since the last time a user called. Hard-coding a date
into Files.Bbs will disable this feature, but may allow some
utilities like Shuffle and FFM to work with OPUS formatted
Files.Bbs listings. If this is important to you, see the
sample control file for information on how to place dates in
Files.Bbs.
Quirks, Peculiarities, and Caveats
There are several aspects of file areas that need to be
mentioned here. Several are useful for monitoring system
usage, while others are merely offshoots of the design of
OPUS.
OPUS will never overwrite a file that exists in a file area.
FIDO<tm> uses an attribute bit to allow files to be
overwritten in the network mail area. OPUS allows you to
configure that bit, but it will ignore it, and never
overwrite a file. Instead, it will change the last character
of the file extension to a sequential decimal number. In
other words, if you have a file called "file.txt" in an
area, and a user tries to upload a file with the same name,
OPUS will name the first upload to "file.tx0". The second
will be "file.tx1" and so on. After ten duplicate files have
been uploaded, OPUS simply stops accepting that filename.
The sysop is free to use any of the embedded commands within
a files.bbs listing. You can record information about the
user in a log if you want, or even place menu instructions
in this file if you wish, although it serves no purpose.
(See the Embedded Commands section below). Of primary
importance here are the line privilege commands. and rest of
file privilege codes.
WARNING!!! Shuffle will suffer extreme
delusions if you use it with embedded
commands. Use the built in OPUS commands to
manage files if you use these codes in your
Files.Bbs listings.
External File Transfer Programs
OPUS supports several file transfer protocols in the form of
external programs. In other words, you must have another program
besides OPUS to allow users to make use of these commands.
Currently, the author of OPUS is working with the authors of
OPUS!Comm to make a generic external transfer program interface.
Future versions of OPUS will allow you to specify any protocol
for which you can provide the code for as long as it meets the
specifications for the OPUS interface.
OPUS Sysop Manual - Page 37
Sliding Window Kermit
Super Kermit is supported in the file CKERMIT.EXE by Jan A.
van der Eyk. You must tell OPUS where this file is in the
control file. If present, users may use this fast, full-
duplex protocol for both upload and download. Many thanks to
Columbia University for developing this outstanding file
transfer protocol.
Windowed Xmodem
This is implemented in the same fashion as Super Kermit. The
required program is WXMODEM.COM. You must specify the
location of this program in the control file in order for it
to be accessed by users. (See the installation kit for
details).
Future versions of OPUS will include support for Chuck Forsberg's
ZModem protocol. We simply ran out of time for this release. This
protocol is running a close race with Super Kermit for the
fastest file transfer routine available.
OPUS Sysop Manual - Page 38
OPUS SYSOP SUPPORT
Installing OPUS Software
OPUS comes with an installation program that will do most of
the work of installing the system for you. You should let
these programs do their job BEFORE you go mucking about with
the way OPUS works. Manual installation is NOT recommended
at all. See the installation kit for further details.
The Control File
The primary emphasis in OPUS is speed. Everything possible
has been done to make OPUS work as quickly and efficiently
as possible. In order to increase the speed of loading the
program, much of the configuration information is contained
in a control file. This file deals with paths and privileges
mainly. All of the options in the control file are
documented, and you should refer to the sample control file
for an explanation of each command.
The Control File Compiler
The compiler takes a text file that you build and turns it
into memory-image information for OPUS to use. The program
OPUS_CTL.EXE MUST be run each time you change your
configuration options. If you do not run the compiler, OPUS
will use your old control file.
To compile an OPUS control file, issue the following command
from the DOS prompt in your OPUS root directory:
OPUS_CTL <control file name>
OPUS_CTL will convert the control file to machine-readable
code. This is done to decrease the work OPUS has to do at
startup time. If a control file was not used, OPUS would
have to do the work of OPUS_CTL each and every time it
executed.
The control file that you can change and is readable
defaults to an extension of "CTL" for "Control". This is the
file that you can manually change. The compiler creates a
runtime image of this information and stores it in a file
named the same as your control file, but with an extension
of "PRM" for "Parameters". You can create as many different
parameter files as you wish. The parameter file that OPUS
uses is specified on the command line when OPUS is invoked.
Command Line Options
OPUS supports several items on the command line. This is
OPUS Sysop Manual - Page 39
primarily for SEADog<tm> support. The following is a list of
things you can specify on the command line:
Parameter File
The first item in the parameter list is the name of the
control file that you wish OPUS to use. You do NOT specify
an extension unless you have changed the extension from
"PRM".
Baud Rate
As with FIDO<tm>, you can specify the baud rate of an
incoming call for use with SEADog<tm>. The syntax is:
-bxxxx
where 'xxxx' is the baud rate of the caller. See the
SEADog<tm> manual for details.
Time
You can tell OPUS how much time remains till the next
SEADog<tm> event. Use this syntax:
-txxx
where 'xxx' is the number of minutes until the next
SEADog<tm> event.
Port
Comm ports can be specified using this parameter:
-px
where x is the communications port. Valid parameters are 1
and 2.
Unpack Mail
If you invoke OPUS with a '-u' switch, it will attempt to
unpack any received mail. If mail packets are found, OPUS
will do whatever you have told it to do in the control file.
The Sysop Menu ("!")
OPUS allows most of the configuration that is not support
file specific to be done online. All sysop commands are
accessed via the "!" command on the main menu. The sysop
menu supports all of the commands accessible using numeric
commands in FIDO<tm>. The big difference is that all of the
OPUS commands are menu driven, and you don't have to
remember obscure syntax rules to use them.
OPUS Sysop Manual - Page 40
A)rea Maintenance
There is not much point in discussing this command further.
It is fully covered in the above sections. It allows you to
specify the paths and privileges for message and file areas.
D)elete Messages
This command allows you to delete messages by date or by
whether they have been received or not. In other words, you
can tell OPUS to delete all messages that have been sitting
around for a while. This prevents your board from becoming
"dated". Usually, you will use this to eliminate messages
that are older than about a month or so. If a user is not
interested enough to call your board at least once a month,
he is not interested in conversing with other users on your
board. Delete by date will unconditionally delete messages
that are older than a time frame you specify.
Delete Received will kill any messages that have already
been received by the user. OPUS will ask if a message should
be deleted at the time it is received, but users do not
always say yes to this question. This command will eliminate
any old received messages that might be lying about.
Both of these features are included in the external program
RENUM by Bob Hartman. The sysop can implement this program
in a fashion that will automatically do the above functions
on a daily basis. See the RENUM documentation for further
details.
M)atrix Setup
This command is the equivalent of the FIDO<tm> "4" command.
It allows you to set your Matrix address(es) and select the
paths to your Matrix message area and Matrix file area.
Addresses are determined by the administration of the
amateur network you belong to. OPUS allows you to specify a
primary and alternate net/node number. This command
maintains the information contained in the file "Mail.Sys"
and is fully compatible with FIDONet<tm>. See your external
mailer program documentation for more information on
addresses.
The paths you set using this command coorespond to a system
file's paths that you have marked as being a Matrix area. In
other words, regardless of what you have set using the A)rea
maintenance command, you must duplicate this information in
this configuration file. This redundancy will probably go
away in future versions of OPUS, but for now, you must
specify your mail paths in two places.
OPUS Sysop Manual - Page 41
Hint: Most sysops set this command once and
forget about it. If, for some reason, you
change the locations of your mail messages
and files, it is very easy to forget to
change this option.
REMEMBER TO CHANGE YOUR MAIL PATHS
IN BOTH A)REA MAINTENANCE AND
M)ATRIX SETUP!!!
E)vent Manager
This option allows you to manage OPUS events. Events tell
OPUS to do certain things at certain times. See the enclosed
"REF_EVNT.DOC" file for further information.
P)riv. Setup
Using this option, the sysop can define the minimum
privilege required to access a menu item. This item allows
you to change the privilege for any item that appears on an
OPUS menu with the exception of the file transfer protocol
menu. You can use this command to configure what menu
options are available to what users, including the sysop
menu. Any menu item in OPUS can be assigned any of the
available privilege levels between TWIT and HIDDEN. See the
enclosed "REF_PRIV.DOC" file for a description of privilege
levels.
O)utside Command
This command allows you to exit OPUS with an ERRORLEVEL
specified in the control file. FIDO<tm> calls this the
"Zero" command. You can use this to allow you to exit to DOS
when you call your system from a remote location. This is a
very powerful command, and should be used with GREAT
caution.
Author's Note
OPUS has been developed over an extended period of time.
This document has existed for a very brief time. As a
result, this section is not quite as complete as it should
be. I am relying very heavily on other support documents
that were never really meant to be used for this purpose. It
is 45 minutes until OPUS is released to the public, and this
document is not complete yet. Within a couple of weeks, a
more complete document will be made available. Until then,
you will have to dig through the technical reference docs to
find the rest of the information that should be in this
document.
OPUS Sysop Manual - Page 42
Events
See "REF_EVNT.DOC"
Embedded Commands
See "REF_CTRL.DOC"
User Access Levels
See "REF_PRIV.DOC"
Sysop's Keyboard
See "REF_KBD.DOC"
OPUS Sysop Manual - Page 43
APPENDICES
OPUS Program and Support File List
----------------- Files used by Opus -------------
The following files are hard-coded in Opus, and cannot
be renamed.
CHGPRIV BBS - C)hange menu
DIR BBS - Area header in each area.
FILES BBS - File listing in each file area.
EDITPRIV BBS - Message editor menu
FILEPRIV BBS - File menu
MAILPRIV BBS - Matrix menu
MAINPRIV BBS - Main menu
MSGPRIV BBS - Message menu
SYSPRIV BBS - Sysop menu
SYSTEM BBS - Main System file
SYSTEM1 BBS - Message / File area 1
SYSTEM2 BBS - Message / File area 2 (etc......)
LASTUSER BBS - User record of last user to go outside.
SCHED BBS - Schedular record
OPUSCHAT TXT - Chat buffer
MAIL SYS - Net/Node number record
OPUSGRAF EXE - Displays settings in Control file
OPUS_CTL EXE - Control file compiler
F1 BBS \
F2 BBS \
F3 BBS \
F4 BBS \
F5 BBS \ Function key display files.
F6 BBS / These can be .GBS for graphics
F7 BBS /
F8 BBS /
F9 BBS /
F10 BBS /
C HLP - C)hange help screen
FILES HLP - File area help screen
MAIL HLP - Matrix help screen
MAIN HLP - Main menu help screen
MSG HLP - Message area help screen
OPUS EXE - Opus itself
The following file CAN be changed in Opus, but
should not be changed if you are running a Opus/Fido setup.
ANSWER BBS - Q)uestionaire answer file
USER BBS - User records
BULLETIN BBS - System Bulletin
WELCOME1 BBS - Initial welcome screen
OPUS Sysop Manual - Page 44
WELCOME2 BBS - Second welcome screen
EDTORIAL BBS - System Editorial
NEWUSER1 BBS - Initial New user screen
NEWUSER2 BBS - Second new user screen
QNEWUSER BBS - Auto questionnaire for new users
QUESTION BBS - Q)uestionaire file
QUOTES BBS - System Quotes
These files can be renamed with impunity.
OPUS CTL - Opus Control File
OPUS LOG - Sysop Log
OPUS PRM - Opus Parameter file (compiled OPUS.CTL)
EDITOR BBS - Help screen for the Editor
INQUIRE BBS - help screen for the Inquire command
LOCATE BBS - help screen for the Locate command
BYEBYE BBS - Logoff screen
CONTENTS BBS - help screen for the Contents command
DAYLIMIT BBS - Shown to users that have no time left for the day.
FILEAREA BBS - List of file areas.
LEAVING BBS - Show to users before they go outside
MSGAREA BBS - list of message areas
RETURN BBS - Shown to users returning from Outside
REP_EDIT BBS - Help for the REPLACE option on the Editor menu
ROOKIE BBS - Welcome 2 screen for users with less than 7 calls.
TIMEWARN BBS - Time limit warning
TOOSLOW BBS - Shown to users that are calling at too slow a baud rate.
WHY_ANSI BBS - help screen for the (ANSI y/n) question
WHY_FB BBS - help screen for the logoff message prompt.
WHY_HU BBS - Help for the G)oodbye command
WHY_PVT BBS - help for the (Private y/n/) prompt on messages.
XFERBAUD BBS - Screen for users that are too slow to up/download
OPUS Sysop Manual - Page 45
Embedded Commands
You can lead a full and meaningful life without using any of these
control codes. In fact, misusing them can probably lead to a lot of
grief. There is nothing here for the novice. If you are not intimately
familiar with Opus and running communication systems, please don't continue.
Most of the control codes assume you know what you are doing. Because the
GBS/BBS files are prepared with a word processor or text editor (ie...not
using any Opus software), there is no way for Opus to check your work.
You should review any files you create using Opus's KEYBOARD MODE before
trusting the file to an on-line situation. The Control-O commands (below)
can be particularly lethal if you aren't careful.
An overabundance of control codes in a BBS/GBS file can make a totally
unmaintainable file. You can build these files using any text editor
that's capable of inserting control codes into files, but I would consider
such a method the "Assembly Language of BBS/GBS Files". A handy Opus sysop
utility would be some sort of program (eg. WYSIWYG BBS/GBS editor) to make
these control codes more readable to the sysop during development. At this
writing, no such utility exists.
[soapbox on]
It's very possible to use these commands to turn a perfectly good system
into one full of gimcracks (useless junk). An Opus sysop has an order of
magnitude more power over his/her system than does a Fido<tm> v11 sysop.
If you take that control, you must also share the responsibility. I think
it's great to add a little spice to a system, but the average user doesn't
call in order to see his/her screen wiggle. These commands are intended
to give the experienced sysop lots of versatility.
They are very easy to over-do!
Also... remember that if you use the MsDOS graphics characters in a BBS/GBS
file, you are going to make non-MsDOS screens look funny because they
won't know how to display the characters. There is absolutely nothing
"non-standard" in Opus itself. If you choose to add such features, you
also need to be prepared to answer questions and/or complaints about them.
[soapbox off]
These control codes can be inserted into any .BBS or .GBS file.
The only exception is DIR.BBS ... which must be a plain text file.
OPUS Sysop Manual - Page 46
THE BASICS -------------------------------------------------
^A ... "Press ENTER to continue: "
^B ... disable ^C/^K aborting
^C ... enable ^C/^K aborting
^D ... Mark that it's a good time for a "MORE?"
^E ... Turn auto-More ON (default)
^F ... COMBINATION COMMAND (see below)
^G ... Ring the caller's bell
^H ... Backspace
^I ... Tab
^J ... Line feed
^K ... Turn auto-More OFF
^L ... Clear screen
^M ... Carriage return
^N ... [ reserved ]
^O ... COMBINATION COMMAND (see below)
^P ... COMBINATION COMMAND (see below)
^Q ... Used for XON/XOFF. Never use this.
^R ... [ reserved ]
^S ... Used for XON/XOFF. Never use this.
^T ... [ reserved ]
^U ... [ reserved ]
^V ... [ reserved ]
^W ... [ reserved ]
^X ... [ reserved ]
^Y ... [ reserved ]
^Z ... MsDOS end of file marker. Never use this.
DATA DISPLAY -----------------------------------------------
NOTE: Both command characters in this section are
CONTROL characters. The `^' symbol means `control.'
For example, `^F' represents CONTROL-F.
^F^A ... quote of the moment
^F^B ... user's name
^F^C ... user's city/state
^F^D ... current date
^F^E ... total number of calls user has made to system
expressed as an ORDINAL number (eg. `1st', `2d', etc)
^F^F ... user's first name
^F^G ... dramatic one-second pause
^F^K ... total minutes on-line in the last 24-hours,
including the time for the current call
^F^L ... length of the current call so far (in minutes)
^F^N ... control-niel (disconnect)
^F^O ... number of minutes remaining for this call
^F^P ... written-out date/time when the user has to be
off the system. NOTE: This uses a built-in Lattice-C
routine which appends the line with a <CR/LF>. You
OPUS Sysop Manual - Page 47
should consider using ^F^P at the END of a line with
no punctuation ... until Prof.Norton and I can get in
and change a couple of things.
^F^Q ... number of calls to system to date (ORDINAL NUMBER)
^F^R ... NET downloads today (download minus upload)
If uploads are greater than downloads, this number
will be negative.
^F^T ... current time
^F^U ... on a questionnaire, all answers are required
^F^V ... on a questionnaire, all answers are optional
^F^W ... total user uploads
^F^X ... total user downloads
^F^Y ... upload:download ratio
QUESTIONAIRES, SURVEYS, ORDER FORMS ------------------------
NOTE: The second character of the commands in this section
is a REGULAR ("printable") character ... NOT a
control character.
HINT: Calm down a little, there are samples at the end
of this file.
^OMd ... store the last `^OR' response to the answer file.
(See `^OR' below). `d' is is a description of the
item which is NOT displayed. The description is
stored in the answer file. Also, see the examples
at the end of this file for more information.
^ONd ... let the user type a line and store it in the user
file. This roughly corresponds to the Fido<tm> "/"
command in questionaires. `d' is for a description
of the entry in the answer file.
^OOf ... open an answer file. `F' is a fully-qualified file
name including path, node, and extemsion.
^OP ... post user information to the answer file
OPUS Sysop Manual - Page 48
FLOW AND USER INTERACTION ----------------------------------
NOTE: The second character of the commands in this section
is a REGULAR ("printable") character ... NOT a
control character.
"Remember-- no matter where you go, there you are."
--Buckaroo Banzai
^OCp ... call MsDOS with the command "p". This is an
embedded "O)utside" command. "P" is some command,
possibly the name of a program or batch file. It
is sent to MsDOS (via Command.Com) without
modification.
^OFb ... "On exit". Declare the name of a GBS/BBS file to
be transmitted if, for any reason, the current file
is terminated.
^OQ ... quit the file immediately
^ORv ... read menu. `V' is a sequence of characters ... a list
of the valid responses. Opus considers all of the
characters between the `R' and the first character
less than or equal to the space character to be part of
the list. In other words, you terminate the list with
a space, tab, end of line, or any other control char-
acter. Refer to an "ASCII CHART" for help in finding
what characters are "below" the space. Opus takes care
of upper/lowercase conversion for you. It is your
responsibility to handle any user prompts: there is no
display associated with this command. "Command
stacking" is fully supported. If the user types an
unrecognized character, Opus will ask him/her to try
again.
^OS ... show another file. The REST of the current line is
considered the name of a BBS/GBS file. Do *not*
include the file's extension. You can include a
drive and path. Most settings (eg Color, Auto-More)
are maintained across file boundries. If the file
you specify doesn't exist, the entire display sequence
is ended and the user is returned to Opus.
^OT ... top of file (dangerous: can produce an "endless loop")
Useful only for handling "fall-through" menu situations
and (with ^B set) for handling niels. (ah-hem)
^OUc ... user response. "C" is a single character. It is the
way to process information from the read menu (^OR)
command. If the user's most recent respons was not
the value you give for `c', the REST OF THE CURRENT
LINE is ignored.
OPUS Sysop Manual - Page 49
PRIV CONTROL -----------------------------------------------
NOTE: The second character of the commands in this section
is a REGULAR ("printable") character ... NOT a
control character.
Dealing with the rest of the file...
^PD ... Below Disgraced don't see rest of file
^PN ... Below Normal don't see rest of file
^PP ... Below Privil (or Privel) don't see rest of file
^PE ... Below Extra don't see rest of file
^PA ... Below Assistant sysop don't see rest of file
^PS ... Below Sysop don't see rest of file
Commands dealing with the rest of the current line...
^PLD ... Below Disgraced don't see rest of line
^PLN ... Below Normal don't see rest of line
^PLP ... Below Privil (or Privel) don't see rest of line
^PLE ... Below Extra don't see rest of line
^PLA ... Below Assistant sysop don't see rest of line
^PLS ... Below Sysop don't see rest of line
FIDO<tm> COMPATIBLE QUESTIONAIRE COMMANDS ------------------
Important: All of the functionality in the following
--------- commands is available with ^O commands.
None of the following are guaranteed
beyond Opus Version Zero. Except for
some unusual circumstance, you should use
the ^O commands instead of these.
+nt ... column one only. Signals a multiple choice answer.
The `n' is actually a digit. EXAMPLE: `+3' would
accept 1, 2, or 3 as an answer. 'T' is normal text.
Opus will ask for the answer after the line of
text is displayed. The digit is
/t ... column one only. 'T' is normal text. After displaying
and text, Opus will wait for the user to type some
sort of character data. The answer is stored in
the answer file.
! ... column one only. If in the most recent multiple
choice question (see `+'), the user picked the highest
option (eg. `3' above), the questionaire will
terminate immediately.
OPUS Sysop Manual - Page 50
* ... column one only. Put some user info (eg.name) into
the answer file.
?t ... column one only. 'T' is normal text which is not
transmitted. Instead, it is stored in the answer
file. This command is a Fido<tm> enhancement. It
is not guaranteed beyond Opus Version Zero. You
should try to use a ^O command instead.
Example:
Question file:
?NAME
/What is your name?
Answer file:
NAME Mark Twain
FOR FILES.BBS ONLY (Fido<tm> compatibility) ----------------
@ ... in column one, stops display for those under
AsstSysop. This is for Fido<tm> compatibility only.
You should not count on this remaining after
Version Zero. Use a ^P command instead.
- ... column one only. turns on WHITE. The display will
remain white until the next file name.
NOTE: There are several ^F commands that deal with the amount
of time a user has remaining. Until the user is totally
through the logon procedure, he/she will have about 10
minutes. The use of these commands prior to the first
MAIN MENU may produce unexpected results.
EXAMPLE 1
CONTENTS OF THE EXAMPLE 1 FILE:
Please select one of these:
H)elp on using the system
T)rojan horse program alert
E)quipment used on-line
Q)uit
Select: ^ORhteq
^L
^OUh^OSc:\opus\morehelp
^OUt^OSc:\opus\trojans
^OUq^Oq
OPUS Sysop Manual - Page 51
We use an AT computer with a 30 meg Seagate disk drive.
The modem is a USR Courier 2400. There is 640k system
memory with 3 megabytes of extended memory which is used
as a RAM disk.
^OT
NOTES FOR EXAMPLE 1:
A short menu system for multiple bulletins. First the menu is displayed.
Then, after "Select: ", Opus will wait for the caller to type `H', `T',
or `A'. For aesthetics, we clear the screen after the menu response (^L).
Then.... if the caller typed `H', we will display the file MOREHELP. If
it's `T', the caller will see TROJANS. If the caller typed `Q', we will
exit the file display and return to Opus. The only unaccounted-for menu
response is `E' ... which is taken care of by the material at the end.
In other words, if the user gets to the part beginning with "We use an...",
he/she must have typed an `E'. It's the "fall-through" case here. Because
Opus doesn't have to change to another file, the fall-through will always
be the quickest. Finally, at the end of the file, we tell Opus to recycle
and display the menu again (^OT).
EXAMPLE 2
CONTENTS OF THE EXAMPLE 2 FILE:
Welcome to the board, ^F^B.
^OOc:\opus\newusers.txt
^OP
What is your occupation? ^ONoccupation
Please find your favorite color ...
B)lue R)ed M)agenta
L)ilac Y)ellow P)uce
Type the first letter of your choice: ^ORbrmlyp
^OMchoice
^OUbBlue! really? Wow, that's my favorite color, too!
Thanks for taking the time to fill out this questionaire.
NOTES FOR EXAMPLE 2:
A short survey. First we do a welcome that includes the user's name (^F^B).
OPUS Sysop Manual - Page 52
Then we setup an answer file called C:\OPUS\NEWUSERS.TXT. Any responses
will be put into this file. Note that the answer file stays open across
files ... should you swap files using ^OS. The first item we put into the
answer file is the user's name (^OP). It is NOT ever necessary to ask a
user "What is your name"... not even a new user. It is easier on the system
and the caller to use the ^OP command rather than being redundant.
The first question deals with the user's occupation. The display would
look like this:
What is your occupation? _
Whether an answer is required depends on whether you have used the ^F^U
or ^F^V commands.
If the caller typed "accountant" then your answer file would contain
this line:
occupation: accountant
The description "occupation" was part of the ^ON command itself.
The next piece of business is a multiple choice question. It works exactly
like the MENU in example #1 above. The addition is `^OMchoice' to store
the user's response in the answer file. For example, if the user selected
RED, the answer file would look like this:
choice: R
Note that if the caller likes BLUE, Opus will get all excited. See the
`^OU' statement. We use this line for two reasons: (1)to show that you
can get exceedingly (excrutiatingly) clever; and (2)you can combine almost
any ^O command.
You can have more than one answer file. Every time you use ^OO, the
current answer file is closed and the new one opened or created. One
side effect involves opening the same file... not advised for normal
operation... but that is one way to force Opus to physically write to
disk any responses it has buffered.
OPUS Sysop Manual - Page 53
For More information on OPUS
There are two ways to find out more about the way OPUS works and to get
questions aswered. If you are having problems with OPUS, contact one of the
InfoNodes. They can be reached at:
OPUSinfo Here modem (214) 991-3381 1/113
OPUSinfo There modem (415) 753-3356 1/114
This is for questions involving specific problems. They can give you answers
to some of the most commonly asked questions.
For general discussions about the usage of OPUS, you should consider
subscribing to the OPUS sysop EchoMail area, called MEADOW. Any of the
distribution nodes can refer you to a tie-in point for this area. If all
else fails, contact Jon Sabol at 124/210 for information pertaining to
MEADOW EchoMail connections.
MEADOW carries the same copyright as OPUS. You are required to act in a
friendly and lawful manner if you participate. We are trying desperately to
keep a casual and constructive atmosphere in the OPUS area. If that is not
your intent, please do not subscribe to the conference. If you wish to
discuss technical aspects of the programs, you are wholeheartedly welcome to
join!!!
OPUS Sysop Manual - Page 54